Vahur Krouverk wrote:
> 
> > Before getting into action setting up a repository of patches it would IMO
> > be good to develop some standards concerning the patches submitted to such
> > a collection.
> [Snip]
> 
> Valid points, but I guess, that it will be better to discuss them in
> unofficial patches group, where such things should belong. I should've
> started it there, not here, so I f-up this post to there.

Good idea.  All right, let's move the discussion.  For those not reading
.programming, my suggestions are cited below:

> > - a common documentation format.
> > - rules for the source code (like marking all changes with preprocessor
> > #ifdef's)
> > - rules for modification of existing patches (bugfixes, improvements).
> > Only by the original author or by everyone?
> > - organizing frequent compiled versions for the most important platforms.
> > Like Vahur pointed out these do not necessarily have to be made by the
> > maintainers of the patch collection.
> 
> - Perhaps some coding guidelines? I know, that this opens can of worms
> and  will be possible cause for endless discussions, but it would be
> good to adopt some sensible coding standards. POV-Ray's code has evolved
> long way and it could be seen from source code: different code layout,
> different naming conventions used, some code uses tabs to ident code etc.

I don't think there is need for layout rules.  Also we would never come to
an agreement here.  Let's focus on those things really important.  

Concerning actual coding rules.  I think the most important rule is to see
how similar things are already implemented and adapt the own style to
this.  Of course there are differences between different parts of the
official POV source but i don't think we really need that precise
guidelines.  After all the patch author should be able to code his stuff
without checking against the rules every few minutes.

A few things that should be pretty obvious:

- use the POV_OSTREAM/POV_ISTREAM stuff to read and write files
- use the standard preprocessor macros (from vector.h) for vector
calculations and not own ones.
- use 'X', 'Y' and 'Z' to access the vector elements and not numbers.
- free memory you have allocated :-)
- use the POV_MALLOC etc. to allocate memory.

I think creating an exhaustive list of such things would be pretty much
work and so far most patches i have seen follow these basic rules very
well.

And finally rules only make sense if they are fairly simple and easy to
follow.  If the patch collection maintainers spend their whole time
reviewing patches and checking if the submissions comply with the rules
the whole thing won't work.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 13 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message